I'm pretty sure this is incorrect because it seems like it would append entries to the end?

This one change is why I still have it marked as draft, the issue is some GCC versions that are in the official ports repository (including the default one if I recall correctly) set their own rpath which is needed for binaries to work. I'm not sure how to really deal with that in a different way.

AFAIU our script tries to set a combined rpath, with z_vcpkg_calculate_corrected_rpath considering the original rpath as reported by patch_elf.
And there is a test port, scripts/test_ports/vcpkg-fix-rpath.

AFAIU our script tries to set a combined rpath, with z_vcpkg_calculate_corrected_rpath considering the original rpath as reported by patch_elf. And there is a test port, scripts/test_ports/vcpkg-fix-rpath.

Right but as far as I can tell there's no handling for system rpaths. I noticed something similar on NetBSD where official GCC 14 sets the rpath to "/usr/pkg/gcc14/x86_64--netbsd/lib/.:/usr/pkg/gcc14/lib/." and this just gets overriden by vcpkg. This can get fixed by just setting a correct LD_LIBRARY_PATH but that's really a half fix, what should really be done?

What is meant by "system rpath" in your answer?

What is the final rpath which want for a given "system rpath" and executable in the vcpkg installed tree? Give a concrete example, as if writing a test case.

What I see is that our script calls "${PATCHELF}" --print-rpath "${elf_file}". Doesn't this include the rpath which is to be retained?

If yes, then we know that it is passed as readelf_output to

            z_vcpkg_calculate_corrected_rpath(
              ELF_FILE_DIR "${elf_file_dir}"
              ORG_RPATH "${readelf_output}"
              OUT_NEW_RPATH_VAR new_rpath
            )

Doesn't the output new_rpath include the rpath which is to be retained?

What is meant by "system rpath" in your answer?

When the rpath is set by the compiler by default (and really as a requirement) because the system libraries for the specific compiler are not in the default dynamic linker path. NetBSD and DragonFly use this when you have multiple versions of GCC installed each with their own version of libstdc++, etc.

What is the final rpath?

This log shows that the rpath is read correctly, it just gets replaced entirely by vcpkg:

-- Adjusted RPATH of ... (From '/usr/pkg/gcc14/x86_64--netbsd/lib/.:/usr/pkg/gcc14/lib/.:lib' -> To '$ORIGIN:$ORIGIN/../../lib')

And once again checking with patchelf after the install:

$ patchelf --print-rpath ...
$ORIGIN:$ORIGIN/../../lib

The current default behavior is to only keep entries with $ORIGIN.
There is an X_VCPKG_RPATH_KEEP_SYSTEM_PATHS variable to keep all entries - you could set in the triplet file.

(Yes, it will keep all entries, including those set by the port. I'm not sure this is the solution. The alternative is to provide/detect what the compiler sets in a controlled way, and put this on a positive list.)